Subject: Elimination of LLC connection in HPR

From: "Derek W. Bolton" <[email-masked]>
Date: Mon, 7 Aug 95 14:23:39 EST

In message "Re: Elimination of LLC Connection in HPR", Jim Cobban 
writes:

> could you point
> out to me the location of the statement in the APPN architecture that CS
> expects the XID to be reliably delivered. 

Under "Rules for DLC Operation on ABM Links", the reader is referred to
the TR Network Architecture Reference.  In the latter document it is
made clear that the "DLC" is responsible for retry of XID commands.
Moreover, there is no cmd/rsp discrimination on the XID transfer between
the DLC and the higher layer.  

While this is a lovely architecture, most LLC implementations don't want
to keep link station state information prior to Connect.  As a result, 
this part of the (APPN view of) DLC function usually ends up in a front-
end (to the LLC product) implemented within the APPN product.  VTAM and
CM are two examples.

So from the point of view of APPN architecture, XIDs are transported
semi-reliably:
- either the XID I send will get to the remote, or I will receive another 
  XID from the remote
- I might get extra copies of XIDs from the remote, and I must answer all 
  of them (until XID phase complete)

Anyway, you and Dave seem to have reached agreement on this.
The burning question, surely, is link outage detection.  (I always assumed 
that was the reason the LLC2 link is required.)  I see no alternative but 
to architect (within HPR) keepalive handshakes on the LLC1 connections.
These handshakes should only occur when there has been no data
(in one direction) for a while, so is no great traffic overhead.

This does not resolve the second SAP problem.  The performance argument 
used to justify the second SAP would be equally valid for the keepalive
traffic.  (Note: 0 = 0 is one example of equality.)   One solution might 
be to allocate an NCE for this traffic.  That allows the frames to be 
delivered with no special logic by ANR.  (Has the information regarding 
the link over which the frame flowed been lost by the time it reaches 
the NCE?  If so, just repeat the info within the body of the frame.)  
Would that work?

- Derek

|   The opinions expressed are those of the author and do not necessarily
|   represent the opinions of Metaplex P/L or Cisco Systems

---

From: Dave Finnie <[email-masked]>
Date: Mon, 7 Aug 1995 14:54:04 +1000

> (in one direction) for a while, so is no great traffic overhead.

I agree.

> the NCE?  If so, just repeat the info within the body of the frame.)  

I like the idea of using a separate (or particular) NCE for the keep
alive traffic. Because NCEs are administered locally, this NCE value
would need to be transmitted via XID - and potentially a different NCE
value could be used in each direction on a link, but that is not a big
issue.

Jim, Derek, what do you think ?

Dave